Windows Phone 7 : Using the Touch Screen (part 1) - Reading Raw Touch Data

All touch input from the screen is obtained using a class within XNA called TouchPanel. This provides two mechanisms with which input information can be obtained: raw touch point data and the Gestures API.

The raw touch point data provides a collection of all current input points on the screen ready to be interpreted in whichever way the program desires. Each touch point identifies whether its touch is new, moved, or released; and allows its previous coordinate to be obtained if appropriate, but nothing more is provided. It is therefore up to the application to interpret this data and handle it as appropriate for the game.

The advantage of the touch point data is that it gives us the most flexible access to multitouch inputs. It also offers the most straightforward method for reading simple input if nothing more complex is required.

The Gestures API recognizes a series of types of input that the user might want to use, such as tap, double tap, or drag. By telling XNA which gestures we are interested in, it will look for these movement patterns and report back to us whatever it finds.

This greatly simplifies many types of input that would be more difficult to recognize and manage using the raw touch point data. The main disadvantage of using gestures is that they are primarily single-touch in nature (with the exception of the pinch gesture which uses two touch points). If you need to be able to gain full access to multiple simultaneous input points, the raw touch point data might be more suitable.

Let's look at how each of these systems is used in detail.

1. Reading Raw Touch Data

When reading the current touch points from the screen, we poll for information: we make a call out to the device and ask it for its current state.

This is in contrast with the way you might be used to obtaining data in desktop applications, which tends to be event driven: each time the operating system detects that something has happened, it queues up an event.

Event-driven systems tend not to "miss" any events, whereas polling systems can skip inputs if they happen too quickly. If the user taps the screen so quickly that the input state is not polled while the screen contact is made, the button press will be missed entirely.

The advantage of polling, however, is that it is fast, easy to use, and provides information at exactly the point where we need it. When you want to see if your player should shoot, you simply check to see if a screen location is currently being touched. This check can take place anywhere in your game code rather than having to be placed within an event handler.

To read the touch points, we simply call the TouchPanel.GetState function. It returns a TouchCollection, inside which we will find a TouchLocation object for each touch point that is currently active. If the collection is empty, the user is not currently touching the screen. If multiple location objects are present, multiple touches are active simultaneously.

Listing 1 shows a simple piece of code in a game class's Update method that reads the current touch points and displays the number of touch points returned to the debug window.

Example 1. Retrieving the current TouchPanel state

protected override void Update(GameTime gameTime)
    {
        // Allows the game to exit
        if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)
            this.Exit();

        // Get the current screen touch points
        TouchCollection touches = TouchPanel.GetState();
        // Output the touch count to the debug window
        System.Diagnostics.Debug.WriteLine("Touch count: " + touches.Count.ToString());

        base.Update(gameTime);
    }

					  

When developing with the Windows Phone emulator, you can, of course, simulate touching the screen by clicking the emulator window with the mouse cursor. If you are running Windows 7 and have a touch-sensitive monitor, the emulator has full support for genuine touch input—including multitouch if your monitor is capable of supporting it. However if you lack a multitouch monitor, it is very hard to develop multitouch applications within the emulator, and using a real device is the only way to properly test your game in this case.

1.1. The Life and Times of a Touch Point

When the user touches the screen, we find a TouchLocation object in the collection returned by TouchPanel.GetState. Contained within this location object are the following properties:

• Id returns a unique identification value for this touch point. As long as the user maintains contact with the screen, location objects with the same Id value will continue to be sent to the application. Each time a new touch is established, a new Id value will be generated. This is very useful for multitouch input because it helps tell which point is which, but for single-touch input we can ignore it.

• Position is a Vector2 structure inside which the touch point coordinate is stored.

• State stores a value that helps us determine whether the touch point is new or has been released by the user.

When the state is polled when a new touch point has been established, the State of that touch point will be set to the enumeration value TouchLocationState.Pressed. If you are interested only in when contact is established, check for this state in your location objects. This is the equivalent of a MouseDown event in a WinForms environment.

When the state is polled and a previously reported touch point is still active, its state will be set to Moved. Note that it doesn't matter whether the point actually has moved or not, this state simply means that this is an established touch point that is still present. You will see how we can determine whether it really has moved in a moment.

Finally when the state is polled and a previously reported touch point has been released, it will be present within the touch collection for one final time with a state of Released. This will always be present once the touch point is released, so you can rely on the fact that every Pressed point will have a corresponding Released state. If the screen is tapped very quickly, it is entirely possible to see a point go straight from Pressed to Released without any Moved states in between.

1.2. Finding a Touch Point's Previous Location

For TouchLocation objects whose State is Moved, we can ask the TouchLocation for the point's previous location by calling its TryGetPreviousLocation method. This will return a Boolean value of true if a previous position is available or false if it is not (which should be the case only if the State value is Pressed). The method also expects a TouchLocation to be passed as an output parameter, and into this the touch point's previous location will be placed.

Listing 2 shows a simple Update function that displays the state, current position, and previous position of the first detected touch point.

Example 2. Retrieving a touch point's previous location

protected override void Update(GameTime gameTime)
    {
        // Allows the game to exit
        if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)
            this.Exit();

        // Get the current screen touch points
        TouchCollection touches = TouchPanel.GetState();
        // Is there an active touch point?
        if (touches.Count >= 1)
        {
            // Read the previous location
            TouchLocation prevLocation;
            bool prevAvailable = touches[0].TryGetPreviousLocation(out prevLocation);
            // Output current and previous information to the debug window
            System.Diagnostics.Debug.WriteLine("Position: " + touches[0].Position.ToString()
                         + " Previous position: " + prevLocation.Position.ToString());
        }

        base.Update(gameTime);
    }

					  

Note that TryGetPreviousLocation gives back a TouchLocation object, not a Vector2, so we can interrogate its other properties, too. It gives access to its State property, which allows a touch point to tell whether it is receiving its first Move state (this will be the case if its previous location's state is Pressed). It is not possible to obtain additional historical information by further calling TryGetPreviousLocation on the previous location object: it will always return false.

If you want to experiment with this, take a look at the TouchPanelDemo example project. This project provides a simple TouchPanel display that places a circular object at the position of each detected touch point. It supports multitouch input and will display the first touch point in white, the second in red, the third in blue, and the fourth in green. Any additional touch points will display in white. When the touch point is released, the circle will fade away into nothing.

All the while this is running, information about the first returned touch point will be written to the debug window. This includes the point's Id, State, Position, and previous Position. From this information you will be able to see the sequence of State values that are returned, see the previous Position for each touch point, and observe the behavior of the previous Position for Pressed and Released touch points.

1.3. Touch Panel Capabilities

If you need to know how many simultaneous touch points are available, you can ask the TouchPanel for this information. Its GetCapabilities method returns a TouchPanelCapabilities object, from which the MaximumTouchCount property can be queried.

All devices are required to support a minimum of four touch points, so anything you write should be able to rely on being able to read this many points at once. In practice, this number is probably quite sufficient for most games.

The only other useful capability property is the IsConnected property, which tells you whether a touch panel is currently connected to the device. For Windows Phone 7 games, it will always return true, but the property might return other values for XNA games running on other platforms (Windows or an Xbox 360, for example).

1.4. Working with Rotated and Scaled Screens

It's very useful being able to read the touch screen coordinate, but what happens if the game is running in a landscape orientation? Do we need to swap over the x and y coordinate values to find out where the touch point is relative to our game coordinates?

You will be pleased to find that the answer is no; XNA automatically takes care of this for us. We don't need to pay any attention at all to screen orientation because the screen coordinates will be translated into the same coordinate system that we are using for rendering.

Taking this concept even further, XNA does exactly the same thing when scaling is in effect. If the back buffer is set to a size of 240 × 400, for example, the touch point coordinates will be automatically scaled into exactly the same range. No special processing is required for these configurations at all.

Try changing the back buffer size in the TouchPanelDemo game class constructor to experiment. You will see that both rotated and scaled output provides correspondingly rotated and scaled input values. This is a very useful feature that greatly simplifies working with touch coordinates under these conditions.